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Differentiated charging in packet data networks 
Field of the invention 

5 This invention pertains to the area of charging in mobile packet data networks. More par- 
ticular, the invention relates to real time based differentiated charging of pre-paid ser- 
vices in General Packet Radio Services (GPRS) networks. 

Background of the invention 

10 

As in most businesses it is important for telecom operators to price differentiate services 
to their users in order to maximise profits. Parameters such as duration of telephone 
conversation, user class of service, distance, time of day of conversation and user ser- 
vice classes have been used in pricing models allowing for high a capacity utilisation. 
15 Recently, the advent of GPRS has made it possible to charge customers, according to 
the amount of data, which is transmitted to and from the mobile terminal in question, 
such that the user is not charged for downtime and interruptions. 

Mobile pre-paid subscriptions, i.e. a subscription type involving a fixed credit limit often 
20 associated with the acquisition of a "pre-paid" SIM card, have recently shown strong 
growth. As opposed to traditional subscribers, which can be billed after the service is 
delivered, operators need the ability to terminate services to pre-paid customers in case 
the credit limit of a given user is reached. Since the service delivered to the user may 
involve many operators, possibly virtual operators, an exact and prompt measurement of 
25 service utilisation is therefore needed. Pre-paid services, has therefore necessitated an 
ability to charge in "real time". 

It is believed that new services such as MMS will be one important driver for the change 
to 3G networks. A consistent pricing model of such services is believed to be important 
30 for users to adopt them. Advantageously, the user should expect a fixed "low" price level 
for transmitting a MMS, such that the service is perceived as being equivalent to other 
competing services, such as sending a post card. It is noted that a picture of a given 
resolution may be of varying data size depending on the coding principle and the motive 
captured. 

35 

According to the 3Yd generation partnership project (3GPP) technical specification, 3G 
TS 23.060 a common packet domain Core Network is used for both GSM and UMTS. 
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Such a system has been shown in fig. T. A similar system has been shown in 
WO99/05828. 

The above Core Network provides packet-switched (PS) services and is designed to 
5 support several quality of service levels in order to allow efficient transfer of non real- 
time traffic (e.g., intermittent and bursty data transfers, occasional transmission of large 
volumes of data) and real-time traffic (e.g., voice, video). One class of quality of service 
pertains to a low throughput and a low delay; another class pertains to higher throughput 
and longer delay and a further class pertains to relatively long delays and high through- 
10 put. 

Applications based on standard data protocols and SMS are supported, and interworking 
is defined with IP networks. Charging is rendered flexible and allows Internet Service 
Providers to bill according to the amount of data transferred, the QoS supported, and the 
15 duration of the connection. 

Each PLMN has two access points, the radio interface (labelled Urn in GSM and Uu in 
UMTS) used for mobile access and the R reference point used for origination or recep- 
tion of messages. 

20 

An interface differs from a reference point in that an interface is defined where specific 
information is exchanged and needs to be fully recognised. There is an inter PLMN inter- 
face called Gp that connects two independent packet domain networks for message ex- 
change. There is also a PLMN to fixed network (typically a packet data network) refer- 
25 ence point called Gi. 

There may be more than a single network interface to several different packet data (or 
other) networks. These networks may both differ in ownership as well as in communica- 
tions protocol (e.g., TCP/IP etc.). The network operator should define and negotiate in- 
30 terconnect with each external (PDN or other) network. 

Network interworking is required whenever a packet domain PLMN and any other net- 
work are involved in the execution of a service request. With reference to figure 1, inter- 
working takes place through the Gi reference point and the Gp interface. 
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The internal mechanism for conveying the PDP (Packet Data Protocol) PDU (Packet 
Data Unit) through the PLMN is managed by the PLMN network operator and is not ap- 
parent to the data user. The use of the packet domain data service may have an impact 
on and increase the transfer time normally found for a message when communicated 
5 through a fixed packet data network. 

The packet domain supports interworking with networks based on the Internet protocol 
(IP). The packet domain may provide compression of the TCP/IP header when an IP 
datagram is used within the context of a TCP connection. 

10 

The packet domain PLMN service is an IP domain, and mobile terminals offered service 
by a service provider may be globally addressable through the network operator's ad- 
dressing scheme. 

15 A GPRS Support Node (GSN) contains functionality required to support GPRS function- 
ality for GSM and/or UMTS. In one PLMN, there may be more than one GSN. 

The Gateway GPRS Support Node (GGSN) is the node that is accessed by the packet 
data network due to evaluation of the PDP address. It contains routing information for 
20 PS-attached users. The routing information is used to tunnel N-PDUs to the MS's current 
point of attachment, i.e., the Serving GPRS Support Node. The GGSN may request lo- 
cation information from the HLR via the optional Gc interface. The GGSN is the first 
point of PDN interconnection with a GSM PLMN supporting GPRS (i.e., the Gi reference 
point is supported by the GGSN). GGSN functionality is common for GSM and UMTS. 

25 

The Serving GPRS Support Node (SGSN) is the node that is serving the MS. The SGSN 
supports GPRS for GSM (i.e., the Gb interface is supported by the SGSN) and/or UMTS 
(i.e., the lu interface is supported by the SGSN). 

30 In order to access the PS services, an MS shall first make its presence known to the 
network by performing a GPRS Attach. This makes the MS available for SMS over PS, 
paging via the SGSN, and notification of incoming PS data. According to the Attach, the 
IMSI (International Mobile Subscription Identity) of the mobile station (MS) is mapped to 
one or more packet data protocol addresses (PDP). 

35 
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At PS Attach, the SGSN establishes a mobility management context containing informa- 
tion pertaining to e.g., mobility and security for the MS. 

In order to send and receive PS data, the MS shall activate the Packet Data Protocol 
5 context that it wants to use. This operation makes the MS known in the corresponding 
GGSN, and interworking with external data networks can commence. 

At PDP Context Activation, the SGSN establishes a PDP context, to be used for routing 
purposes, with the GGSN that the subscriber will be using. 

10 

According to the PDP context activation, a network bearer (IP) communication between 
the mobile station and for instance the Internet service provider (ISP) may be estab- 
lished. Moreover, a given class of Quality of Service is assigned for the communication 
to be performed. 

15 

The SGSN and GGSN functionalities may be combined in the same physical node, or 
they may reside in different physical nodes. SGSN and GGSN contain IP or other (op- 
erator's selection, e.g., ATM-SVC) routing functionality, and they may be interconnected 
with IP routers. In UMTS, the SGSN and RNC may be interconnected with one or more 
20 IP routers. When the SGSN and the GGSN are in different PLMNs, they are intercon- 
nected via the Gp interface. The Gp interface provides the functionality of the Gn inter- 
face, plus security functionality required for inter-PLMN communication. The security 
functionality is based on mutual agreements between operators. 

25 The SGSN may send location information to the MSC/VLR via the optional Gs interface. 
The SGSN may receive paging requests from the MSC/VLR via the Gs interface. 

The SMS-GMSCs and SMS-IWMSCs support SMS transmission via the SGSN. Option- 
ally, the MSC/VLR can be enhanced for more-efficient co-ordination of packet-switched 
30 and circuit-switched services and functionality: e.g., combined GPRS and non-GPRS 
location updates. 

User data is transferred transparently between the MS and the external data networks 
with a method known as encapsulation and tunnelling: data packets are equipped with 
35 PS-specific protocol information and transferred between the MS and the GGSN. This 
transparent transfer method lessens the requirement for the PLMN to interpret external 
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data protocols, and it enables easy introduction ot additional interworking protocols in 
the future. 

An Application Server (AS) is connected to the Packet Data Network (PDN) for providing 
5 information. An Internet Service Provider (ISP), the PLMN, or an independent company 
may own the application server. The application server may offer MMS. 

The packet domain logical architecture, as defined in 3GPP TS 23.060, defines the pro- 
tocols involved in the various nodes. Fig. 2 shows the user plane protocol stacks, as de- 
10 fined in the 3GPP TS 23.060 for GSM. Fig. 3 shows the user plane protocol stacks, as 
defined in the 3GPP TS 23.060 for UMTS. 

In both cases shown in fig. 2 and 3, the GTP-U protocol conveys both uplink and 
downlink payload between SGSN and GGSN nodes, the Gn (or Gp in a roaming situa- 
15 tion) interface. Fig. 2 and 3 shall not be explained further as their content is well known 
in the art. 

Charging 

20 In a mobile packet data network, real-time pre-paid charging may rely on the use of 
CAMEL as standardized in 3GPP TS 22.078, 23.078 and 29.078. 

In fig. 4, the charging performed in known GPRS networks have been further illustrated. 
As appears from the figure, the SGSN may belong to a first operator 1 - which may be 
25 denoted as a visitor public land mobile network (VPLMN) and the GGSN may belong to 
a second operator 2 - which may be denoted as a home public land mobile network 
(HPLMN). This node may for instance belong to operator 2. 

Respective Charging Gateway Functionality (CGF) in individual nodes collects charging 
30 records from SGSNs and GGSNs. The HLR (Home Location Register) contains GSM 
and UMTS subscriber information. The HLR stores the IMSI (International Mobile Sub- 
scription Identity) and maps the IMSI to one or more packet data protocol addresses 
(PDP) and maps each PDP address to one GGSN. 
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The SGSN provides S-CDR (SGSN Charging Data Kecord) charging reports relating to 
transmitted traffic according to a PDP context to a CGF. The S-CDR reporting is not per- 
formed on a real time basis, and hence inapt for real time charging. 

5 The GGSN also performs collection of charging information on the same traffic relating 
to a given PDP context, travelling through the GGSN by providing G-CDR (GGSN 
Charging Data Record) reports. The amount of traffic may be slightly different from the 
measurements performed in the SGSN. The G-CDR reporting is not performed on a real 
time basis. 

10 

As indicated in fig. 4, a CAMEL SCP (Service Control Point) node collects charging re- 
ports over the Ge interface using the Camel Application Part (CAP) protocol. The 
CAMEL standard caters for reporting transferred payload volume as a single measure- 
ment, uplink and downlink together. The CAMEL interaction (Ge interface) reports the 
15 appropriate PDP context resource utilization to a pre-paid system (CAMEL GSM-SCF). 
The SGSN however lacks the ability to discriminate different kinds of payload flowing 
through the PDP context. 

The prime basis for charging in a mobile packet data network (GPRS in GSM and UMTS 
20 networks) is anticipated - and indicated by operators - to be the amount of transmitted 
payload in a PDP context. According to 3GPP TS 32.200, it is the "Usage of the radio 
interface " that is to be measured, i.e. measurements are performed on the SNDCP 
layer (Gb interface) for GSM and on the GTP-U layer (lu interface) for UMTS. 

25 Services may be charged for separately, but still provided through the same PDP con- 
text. The payload required to provide the service should not (normally) be accounted for 
with respect to amount of payload to charge. 

A known Packet Inspection and Service Classification (PISC) system interacting with a 
30 GGSN node has been provided and sold by Ericsson under the name "Flexible Bearer 
Charging (FBC) system". Currently, such systems are dealt with under the designation 
Traffic Plane Function (TPF) in 3GPP TR 23.825. The PICS system performs packet in- 
spections for given PDP contexts and assesses the given class of service used for the 
given PDP context. Based on the inspection, the FBC functionality provides reports of 
35 the volume of traffic for the given class of services provided. The FBC may provide vol- 
ume and class for each PDP packet sent or received in a given PDP context. 
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The GGSN lacks a standardized real time charging interface towards a pre-paid system. 
The GGSN moreover lacks a control mechanism to be used for shutting down a PDP 
context, when the user account is empty. 

5 

Fig. 5, 6 and 7 show various known GTP header formats as defined in 3GPP TS 29.060. 
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Summary of the invention 

it is a first object of the invention to set forth a method for a more efficient monitoring of 
charging in a mobile packet data network. 

5 

This object had been accomplished by the subject matter set forth in claim 1 . 

It is a second object of the invention to set forth a packet data unit enabling a more effi- 
cient monitoring of charging in a mobile packet data network. 

10 

This object had been accomplished by the subject matter set forth in claim 6. 

It is a third object of the invention to set forth a gateway node providing a more efficient 
monitoring of charging in a mobile packet data network. 

15 

This object had been accomplished by the subject matter set forth in claim 14 and 15. 

It is a fourth object of the invention to set forth a serving node providing a more efficient 
monitoring of charging in a mobile packet data network. 

20 

This object had been accomplished by the subject matter set forth in claim 16. 

It is a fifth object to set forth a gateway node that provides for charging in a mobile 
packet data network, in cases where service classification cannot be performed momen- 
25 tarily. 

The gateway nodes according to claims 20 and 21, respectively, have achieved this ob- 
ject. 

30 According to the invention true real-time control over resource usage is achieved in both 
HPLMN and VPLMN. Both HPLMN and VPLMN operator's non-chargeable network traf- 
fic is reduced compared to near real-time charging solutions. 

Further objects and advantages will appear from the following detailed description of the 
35 invention. 
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Brief description of the drawings 



Fig. 1 shows an overview of the common domain core network according to the 

5 known 3GPP specification, 

fig. 2 and 3 shows known user plane protocol stacks for GSM and UMTS, respec- 
tively, 

10 fig. 4 discloses a known CAMEL reporting procedure, 

fig. 5 shows the prior art GTP PDU header format, 

fig. 6 shows the prior art extension header format for the GTP PDU format, 

15 

fig. 7 shows the status for respective bit settings for the next extension header 

type of fig. 5, 

fig. 8 is an overall illustration of the preferred embodiments according to the 

20 invention relating to a GPRS network comprising at least a serving GPRS 



support node (SGSN) and a gateway GPRS support node (GGSN), 



fig. I a + b illustrates a charging and IP packet flow including packet construction for 
a first embodiment of the invention, 

25 

fig II a + b illustrates a charging and IP packet flow including packet reception and 
CAMEL reporting for a first embodiment of the invention, 



fig. Ill a + b illustrates a charging and IP packet flow including packet construction for 
30 a second embodiment of the invention, 

fig. IV a + b illustrates a charging and IP packet flow including packet construction for 
a third embodiment of the invention, 



35 fig. 9 



discloses a first embodiment of an extension header type according to the 
invention, and 
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fig. 10 discloses a second embodiment of an extension header type according to 

the invention. 

5 

Description of a first preferred embodiment of the invention 

In figure 8, an exemplary illustration of a preferred embodiment has been shown relating 
10 to a GPRS network comprising at least a serving GPRS support node (SGSN) and a 
gateway GPRS support node. According to the invention, charging information (CI) re- 
lating to a particular PDP context for a given mobile station is gathered in the GGSN / 
PISC and is transmitted in a GTP header extension to the SGSN. The charging informa- 
tion is signalled at reception at the SGSN to a charging node (SCP) associated with the 
15 SGSN. 

According to the invention, after a PDP context is activated for a given user, the GGSN 
resolves the kind of PDP (e.g. IPv4, Ipv6), and resolves the class of service of the PDP 
PDUs at the Gi interface. Examples of such service classes are MMS traffic, stock mar- 
20 ket information, positional information etc. 

The present invention makes use of a Packet Inspection and Service Classification 
(PISC), such as the Ericsson FBC (Flexible Bearer Charging) system, for analyzing GTP 
traffic according to a given PDP context and hence according to a given user. The gate- 
25 way node, GGSN, is communicating with the packet inspection and service classification 
system, PISC, to which IP packets may be communicated for identification of a given 
service class out of a number of predetermined service classes. 

The analysis is performed on a packet-to-packet basis, and provides associated values 
30 of PDP context, estimated class of service value and associated payload volume value. 
The PISC data, in the following denoted class of service data and volume, may be 
evaluated, accumulated and transformed into reports. Since packet inspection is a diffi- 
cult task, it may not always be possible to classify the payload packet transmitted; hence 
at least a non-successfully evaluated class of service value may be assigned to the 
35 class of service data. Depending on the extent the information can be classified, reports 
may be established which allows for a tolerance assessment or worst-case assessment. 
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For instance, it could be an object not to charge for more than provided, should any in- 
accuracy in the system be detected. 

It should be noted that the PISC system could be an integrated part of the GGSN and 
5 the functioning could be based on software. 

The above PISC system interacts with the GGSN and according to the invention the 
GGSN inserts class of service values in the stream of data transmitted to the SGSN. 
From here, the class of service data together with charging information obtained in the 
10 SGSN node is transmitted using normal CAMEL reporting procedures to the CAMEL 
SCP. This route for the charging information (CI) pertaining to a first embodiment of the 
invention has been shown in fig. 8, which will be further dealt with under figs, la and lb. 

There is no restriction as to what and how many classes of services may exist, but the 
15 encoding scheme must be the same at the GGSN and the CAMEL gsmSCF / SCP. 

According to the invention, at least one special extension header is added to a GTP-U 
header for a given GTP packet to be transported, on at least the Gn/Gp interface be- 
tween the GGSN and the SGSN. In this special extension header data related to at least 
20 a particular service class for a given PDP context is stored. It should be noted that the 
class of service data carried in the special extension header might be associated with 
the subsequent payload carried under the extension header. However, the service class 
data of the special header extension is not necessarily associated with the payload of 
the GTP packet, which is carried under the given extension header. 

25 

The GTP header, as shown in figure 5, is flexible since the extension format according to 
the current GTP standard, as shown in figure 6, can be added to a default header. 

According to a preferred embodiment of the invention, the list of GTP header extension 
30 types, defined in 3GPP TS 29.060, is provided with a new GTP-U header extension 
type, which indicates that the extension header comprises class of service information. 
For instance the marker value 01 10 0000 can be used as "next extension header type' 
cf. fig. 5, for indicating that a GTP extension header follows including service class in- 
formation. 

35 
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The extension header type may indicate that the receiver endpoint is not obliged to in- 
terpret the information and that it shall be passed on to the SGSN that transmits the 
GTP-U content towards the radio network. Setting Bits 8 and 7 of the marker value to 
adopt the values 0 and 0 accomplishes this task, cf. fig. 7. 

5 

The above measures will make information available at the CAMEL SCP node, so that 
different ratings can be applied on a per payload class of service basis. 

In fig. 9, a first embodiment of an extension header type is shown. The first octet relates 
10 to the size of the extension header that in this case always has the size of 4 octets indi- 
cated by the length field value of 1. 

The extension moreover comprises a main service class field and a subclass field. The 
provision or the use of the subclass field is optional. As required for extension headers, 
the last octet comprises a field for indication whether a further extension header is added 
15 in the GTP packet. 

In fig. 10, a second embodiment of an extension header according to the invention is 
shown. This extension header is larger than the first one and comprises additionally a 
volume count relating to how big the payload volume is for a given service class. 

20 

According to the preferred embodiment The Payload class of service information in- 
cludes a "Class of service only" if the complete PDP payload in a GTP-U PDU has the 
same class of service or a "Class of service and volume" for other implementations, such 
as if the class of service information applies to part of the PDP payload in a GTP-U PDU 
25 or the class of service information applies (in part or full) to payload conveyed in another 
GTP-U PDU or if the class of service information applies to the PDP payload in more 
than one GTP-U PDU. 

The "class of service only" GTP-U header extension format, shown in fig. 9, is applicable 
30 if the entire PDP PDU payload in the GTP-U packet falls in the same class of service. 

One "class of service and volume" GTP-U header extension, shown in fig. 10, is inserted 
for each class of service, for which volume information shall be conveyed to the SGSN. 
This format is needed for conveying class of service information on uplink payload to the 
35 SGSN. 
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The Main class of service and Subclass of service encoding can be arranged as desired. 
It is envisaged that MMS traffic could constitute a first class of service, positional ser- 
vices constitute another class of service and all other traffic could constitute a third class 
of service. The subclass could be used for an additional level of resolution. 

5 

The SGSN maintains one' counter for the volume of each service class, and subclass if 
provided, for a certain PDP context. 

First embodiment - fig. I a & b 

10 

Fig. la+b illustrates the packet construction for a first embodiment of the invention. 

In step 1 the IP packet arrives at the Gi interface in the GGSN. The IP packet payload is 
extracted. Subsequently the IP packet is identified as part of a PDP context and the IP 

15 packet is stored in GTP-U PDU. The Packet Inspection and Service Classification 

(PISC) analyses the content of the payload and identifies a service class value for the IP 
packet in step 3. Thereafter, a GTP-U extension header containing the identified service 
class value is prepared in the GGSN, confer step 4. This special extension header is in- 
serted, see step 5, as part of the GTP-U PDU for which the service class value was as- 

20 signed. Finally, in step 6, the GGSN sends the GTP-U PDU downstream towards the 
SGSN. 

Fig. II a & b 

25 In fig. II a & b the subsequent actions taken in the GGSN for the first embodiment is illus- 
trated. The GTP-U PDU mentioned above is reaching the SGSN on the Gn interface as 
shown in step 1. In step 2', the service class value is extracted from the extension 
header. The SGSN measures the payload volume of the incoming packet and stores the 
service class value of the payload, step 3'. This volume information is accumulated for 

30 given respective service classes for a given PDP context in the SGSN reporting unit. 

Following normal CAMEL reporting procedures, the SGSN reports CAMEL measure- 
ment, as shown in step 4. More specifically, the Ge interface CAP operation Apply- 
ChargingReportGPRS is augmented with information on classified payload. The class of 
35 service counters are reported to the SCP in a new information element Classified Pay- 
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load in the known ApplyChargingGPRS operation to the SCP. This transfer may for in- 
stance be performed over a SS7 network. 

The SCP, which maintains the balance of the subscriber's account, may use the classi- 
5 fied payload information for rating. The information elements specified in the present 
3GPP specification for the ApplyChargingReportGPRS CAP operation are not affected, 
i.e. payload volumes and thresholds are still reported with total amount of payload. In- 
clusion of measurement reports of classified payload is conditionally added to the Ap- 
plyChargingReportGPRS CAP operation in a backward compatible way. 

10 

The SCP must have a list of service classes that affects the rating of payload transfer. 
The SCP may prepare the SGSN to report only those service classes in the ApplyCharg- 
ingGPRS operation: 

15 Reporting classified payload volume does not mandate classifying all payloads. Such 
"not classified" payload can be inferred from the total measured payload, reduced with 
the sum of all classified payload. The non-classified payload may be assigned to a de- 
fault class as opposed to perform volume charging. 

20 The SCP uses the standard CAMEL procedures to shut down services when the ac- 
count is exhausted. 

One advantage of the invention is that the classified payload measurements - that are 
best produced at the GGSN where the GTP tunnel is ended, the PDP type is known and 

25 the PDP payload is observable - are made available to an SCP over the known Ge inter- 
face from the SGSN without requiring any new interfaces. Moreover, the transfer of ser- 
vice class and size information from the GGSN to the SGSN does not require any new 
GTP PDU type, or any other protocol. The transfer according to the invention would con- 
stitute an optional feature and is a backward compatible extension to the GTP-U PDUs 

30 that are handled by existing SGSN / GGSN. Moreover, given the GGSN provides the 
payload service class information for downlink payload in the same GTP-U PDU as the 
actual payload transfer. The classified measurement fulfils the same accuracy require- 
ments as the local measurement of total downlink payload at the SGSN. Also, the trans- 
fer of service class and volume information from the SGSN to the SCP using the Ge in- 

35 terface is a backward compatible extension to existing CAP operations and do not affect 
prior art CAMEL reporting procedures. 

14 



WO 2005/053224 



PCT/SE2003/001829 



For the embodiment corresponding to figs, la+b and lla+b downstream packets are re- 
ported as shown. Upstream packets may be provided separately using the known 
CAMEL interface. 

5 

In steps 2 and 3, an alternative path is shown for the case wherein both volume count 
and service class is provided in the extension header. In step 2 both the service class 
and volume count is extracted. Consequently in step 3, the values are a stored as sepa- 
rate information of the PDP context. 

10 

Second embodiment - Fig. 1 1 la+b 

In fig III a + b a second embodiment of a charging and IP packet flow according to the 
15 invention has been shown. 

A first down stream IP packet arrives at the GGSN at the Gi interface, step 1 . 

The first IP packet is identified as part of a PDP context and the packet is stored in a first 
20 GTP-U PDU, step 2. 

By way of example, the first IP packet payload class can not be identified separately, 
step 3. 

25 The PISC saves measurement information of the non-classified IP packet payload, step 
4. 

The GGSN transmits the GTP-U PDU downstream towards the SGSN, step 5. 

30 According to step 5', steps 1-5 may be repeated before continuing. 

In step 6, a second exemplary downstream IP packet arrives at the Gi interface. 

The second IP packet is identified as being part of the same PDP context as the first 
35 non-classified IP packet and the received IP packet is stored in a GTP-U PDU, step 7. 

The second IP packet is identified and classified by the PISC, step 8. 

15 
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The first non-classified IP packet is correlated to the second IP packet, so this service 
class is assigned to both the first and the second IP packets, step 9. The correlation may 
be based on the type of used protocol, source address, port number as well as potential 
5 underlying protocol specific information. 

A GTP-U header is prepared with the service-classified identity and associated volume 
count, whereby the volume count represents the sum of the not yet reported volume 
count of the service class for the PDP Context, step 10. 

10 

The GTP-U header is included as part of a second GTP-U PDU for which the classifica- 
tion was performed, step 1 1 . 

Finally, the GGSN transmits the second GTP-U PDU to the SGSN. 

15 

When the two above GTP-PDUs are received in the SGSN, the PISC data is extracted in 
so far as extension headers are provided in respective GTP-PDUs. This procedure cor- 
responds closely to the one illustrated in fig. Ha and b. 

20 An alternative embodiment could also be envisaged that identifies a first service class for 
a first but not a second later IP, packet - in this case, the classification should be stored 
and assigned for the second packet 

In the second and third embodiment explained above, the PISC performs a partial or in- 
25 complete classification and stores incomplete classifications and associated volume 

counts in memory. The term partial classification should be understood in the sense that 
it is not possible to unambiguously identify the given payload, of a given volume count, 
to a specific service class. This means that the given volume count cannot be reported 
as part of a specific class at that particular moment. Additional information gathered from 
30 succeeding payload packets of the same service are needed for an unambiguous classi- 
fication of the aggregated volume of the payload in question belonging to a given PDP 
context. 

Third embodiment - Fig. IVa+b 

35 
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In fig IV, an example has been shown which relates to a PDP context session in which 
messages are both transmitted upstream (on the up-link) and downstream (the down- 
link). 

5 In step 1 , an upstream GTP-U PDU arrives at the Gn interface of the GGSN. 
A first IP packet is extracted from the GTP-PDU, step 2. 

The first IP packet payload is identified and classified by the PISC if possible, step 3. By 
10 way of example the first IP payload is identified as belonging to a first service class. 

The PISC saves information for the classified first IP packet associated with the given 
PDP context, step 4. A cumulative volume pertaining to a respective service class and 
PDP context is updated in the PISC. 

15 

The GGSN sends the upstream IP packet towards the Gi interface, step 5. 

The steps 1-5 may be repeated before continuing. If more upstream packets arrive and 
no downstream packet arrives, the volume count of classified upstream payload packets 
20 are accumulated until a downstream payload packet for the same PDP Context appears. 

If no more upstream packets or if a downstream packet arrives, the process moves on to 
step 7, whereby a first arriving downstream payload packet will carry the in PISC accu- 
mulated classified volume counts for the same PDP Context. 

25 

If no more upstream packets and no downstream packets arrive, the process moves on 
to step 10. 

The procedures of both classification and of accumulation of volume reports from both 
30 fully classified and partial classified payload volume are maintained as long as the PDP 
Context is active. Not yet reported volume counts at PDP Context deactivation are sim- 
ply discarded or is transmitted in an empty GTP-U packet. 

In step 6, the SGSN may await more IP packets belonging to the PDP context and re- 
35 sume the steps 1 - 5 for subsequent packets. When a downstream second IP packet 
arrives belonging to the same PDP context the accumulated classified volume counts 
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are reported, arranging associated values of service class and volume count in a sepa- 
rate extension header. 

The downstream second IP packet is stored in a GTP-U PDU, step 7. 

5 

The second IP payload is identified and classified by the PISC, step 8. By way of exam- 
ple, the second IP payload is identified as belonging to a second service class. 

In step 9, the second IP packet is identified as part of the same PDP context as the ear- 
10 Her non-reported first IP packet payload measurement. 

A first GTP-U extension header is prepared carrying the service class identity from at 
least one saved measurement of upstream IP packets, step 10. Byway of example, the 
payload is of a first service class type. 

15 

The first GTP-U extension header, step 1 1 , is included as part of the downstream GTP- 
UPDU. 

A second GTP-U extension header is prepared with the identified service class identity 
20 of the downstream second IP packet, step 12. 

The second GTP-U extension header is included as part of the common GTP-U PDU, 
step 13. 

25 The GGSN transmits the common GTP-U PDU, step 14. 

In the above embodiment above, the GTP-PDU carry more than one extension header. 
One extension header is added for each new category being reported. 

30 According to the embodiments set out above, true real-time control over GPRS resource 
usage is achieved. The first embodiment has the advantage of providing a very fast re- 
porting. The second and third embodiments do not provide for as swift a reporting as the 
first embodiment, but provides a higher reliability of the service classification. 

35 Thereby GPRS pre-paid service is accomplished which provides for separate charging 
per service utilisation of payload transport. According to an advantageous aspect of the 
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invention, the service-related payload is deducted from the gross payload, whereby 
charging can be accomplished for both PDP context usage and services. 

As mentioned above, existing protocols and interfaces, such as the known CAMEL re- 
porting mechanisms are used such that the embodiments are backward compatible with 
the current 3GPP standard. 
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Abbreviations 

CAMEL Customised Applications for Mobile network Enhanced Logic 

CDR Charging Data Record 

5 CGSN A node combining SGSN and GGSN functionality 

Ge CAMEL interface between GSM-SCF and SGSN nodes 

GGSN Gateway GPRS Support Node 

Gn Interface between two GSNs within the same PLMN 

Gp Interface between two GSNs in different PLMNs. The Gp interface al- 
io lows support of GPRS network services across areas served by the co- 
operating GPRS PLMNs 

GPRS Packet Services for GSM, UMTS or GERAN systems 

gprsSSF GPRS Service Switching Function 

GSM Global System for Mobile communications 

15 GSM-SCF GSM Service Control Function (in spite of the "GSM", applies to GPRS 

and UMTS as well) 

gsm SCF GSM Service Control Function 

GTP GPRS Tunnelling Protocol 

GTP GTP variant for transporting CDR information 

20 GTP-U GTP User Plane 

HPLMN Home PLMN 

MMS Multimedia Messaging Service 

MS Mobile Station, the MT and TE together 

MT Mobile Terminal 

25 PDP Packet Data Protocol. 

PDU Protocol Data Unit 

PLMN Public Land Mobile Network 

SCP synonym for GSM-SCF 

SGSN Serving GPRS Support Node 

30 TE Terminal Equipment 

UMTS Universal Mobile Telecommunications System 

VPLMN Visited PLMN 
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